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ABSTRACT 


Engineer  command  and  control  in  a  mechanized  corps  is  a  complex  system.  The 
current  doctrine  for  engineer  force  structures  is  inadequate.  Three  command  and 
control  alternative  force  structures,  identified  in  the  Engineer  Structure  Study,  are 
evaluated  to  determine  which  structure  best  supports  a  mechanized  corps.  The 
analysis  is  based  on  the  results  of  a  Stochastic,  Timed,  Attributed  Petri  Net  timed 
stepped  simulation.  The  model  used  in  this  simulation  was  constructed  using  an 
interactive  graphical  design  tool,  called  Modeler,  by  a  team  including  the  software 
developer  ALPHATECH,  the  U.S.  Army  Engineer  Center,  and  the  Training  and 
Doctrine  Analysis  Command.  This  was  the  Army's  first  use  of  Modeler.  The  C2 
performance  of  the  engineer  staffs  is  simulated  for  each  of  the  three  force  structures 
by  simulation  message  traffic  and  processing  for  15  days  of  war  in  three  settings, 
offensive,  defensive  and  transitional  from  offensive  to  defensive.  The  force  structures 
are  then  analyzed  by  comparing  simulation  output  using  three  measures  of 
performances:  Processing  Capacity,  Message  Quality,  and  Message  Processing  Speed. 
The  Division  Engineer  alternative  consistently  out  performs  the  Base  Case  and 
Company  Restructure  alternatives  for  each  measure  of  performance  and  in  each  of  the 
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L  INTRODUCTION  AND  BACKGROUND 


A.  INTRODUCTION 

The  purpose  of  this  thesis  is  to  determine  the  best  engineer  force 
structure  to  support  a  corps  composed  of  armored  and  mechanized  divisions. 
This  corps,  called  the  heavy  corps,  is  the  backbone  of  the  defense  of  Central 
Europe.  A  better  engineer  force  structure  is  necessary  because  of  the 
acknowledged  engineer  support  problem  summarized  by  Major  General  Kem, 
former  Commandant  of  the  U.S.  Army  Engineer  Center.  "The  combat 
engineer  finds  himself  supporting  a  rapidly  modernizing  battlefield  with  a 
cumbersome  World  War  II  organizational  architecture"  [Ref.  1], 

The  nature  of  the  problem  can  be  discussed  after  describing  the  three 
alternatives.  These  alternatives  were  developed  in  the  Army  study  called  the 
Engineer  Structure  Study  (ESS).  The  three  alternative  force  structures 
analyzed  follow: 

•  Base  Case  (BC)  -  is  the  current  force  design  which  consists  of  one 
divisional  engineer  battalion  organic  to  each  division.  Additionally, 
there  exists  an  engineer  brigade  which  provides  reinforcing  engineer 
units  to  the  division,  as  well  as  support  to  the  rest  of  the  corps. 

•  Company  Restructure  (CR)  -  in  this  force  the  line  companies  of  the 
divisional  engineer  battalion  are  strengthened  with  additional 
personnel  and  equipment.  These  assets  are  reallocated  from  corps 
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units.  The  corps  engineer  brigade  still  retains  assets  to  weight  the 
main  effort,  and  provides  support  to  the  rest  of  the  corps. 

•  Division  Engineer  (DE)  -  in  this  force  the  divisional  engineer  assets 
are  completely  restructured.  Assets  taken  from  the  corps  are  used 
to  form  a  divisional  engineer  headquarters  with  three  downsized 
engineer  battalions  organic  to  the  division.  This  provides  an  organic 
command  and  control  structure  to  the  division  not  present  in  the 
other  alternatives.  The  corps  engineer  brigade  retains  sufficient 
assets  to  weight  the  main  effort,  and  provide  support  to  the  rest  of 
the  corps. 


An  understanding  of  the  use  of  symbols  is  required  to  describe  the 
alternatives  in  greater  detail  and  illuminate  the  engineer  support  problem. 
The  unit  symbols  used  to  describe  the  alternatives  are  defined  in  FIG(l).  The 
boundaries  of  a  typical  four  division  corps  are  shown  in  FIG(2).  Since  the  four 
division  areas  are  similar,  we  magnify  the  engineer  organization  in  the  corps. 
Only  the  area  so  surrounded  by  the  use  of  a  dashed  line  is  portrayed  in  the 
graphical  depiction  of  the  alternatives. 

The  base  case  alternative  is  illustrated  in  FIG(3).  From  this  figure,  one 
can  see  that  corps  engineer  units  have  complicated  command  and  support 
channels.  Also,  they  are  required  to  provide  significant  engineer  forces  to 
support  maneuver  operation  at  the  division  and  brigade  level.  As  a  result 
corps  performance  may  be  adversely  affected. 
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Corps  Headquarters 
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Figure  1 


Figure  2 


Base  Case  Alternative 


The  command  and  support  requirements  cause  the  corps  engineer  units 
to  communicate  with  both  their  parent  unit,  and  the  maneuver  unit  they  are 
supporting.  Supplies  must  go  through  long  channels  and  must  pass  through 
the  supported  division’s  area.  Under  certain  conditions  orders  from  maneuver 
commanders  must  pass  through  the  corps  engineer  command  channels.  This 
extended  and  complex  command  channel  can  often  cause  the  corps  engineer 
units  to  be  unresponsive  to  the  maneuver  commanders. 

The  reliance  of  the  maneuver  brigades  on  corps  engineer  units  for 
engineer  support  operations  in  the  forward  battle  area  leads  to  additional 
problems.  Corps  engineer  units  have  different  equipment  and  standard 
operating  procedures.  This  leads  to  difficulties  in  synchronization,  agility  and 
initiative. 

The  company  restructure  alternative  is  very  similar  to  the  base  case  and 
is  illustrated  in  FIG(4).  The  main  difference  is  that  personnel  and  equipment 
are  reallocated  from  corps  units  into  the  divisional  engineer  emits.  This 
reduces  the  need  for  the  maneuver  commanders  to  rely  on  corps  engineer  units 
in  the  forward  battle  area,  but  command  and  support  problems  still  exist  and 
other  problems  arise. 

It  may  be  seen  in  FIG{4)  that  control  of  the  engineers  in  the  forward 
battle  area  is  less  complicated  than  in  the  base  case.  An  offsetting  feature  of 
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Company  Restructure  Alternative 


Corp6  Engineer  Units 


this  is  that  the  additional  personnel  and  equipment  reallocated  to  the  divisions 
appears  with  no  additional  command  and  control  structure.  It  is  anticipated 
that  the  division  and  brigade  engineer  staffs  will  quickly  become  overwhelmed. 
This  is  also  indicated  in  the  alternative  illustration  FIGK4).  The  command  and 
support  appears  complicated  in  the  armored  division’s  area. 

The  third  alternative,  division  engineer,  totally  restructures  the  way 
engineers  support  the  corps.  Under  this  alternative,  command  and  support 
relationships  are  simplified,  as  can  be  seen  in  FIGK5).  In  addition,  engineers 
in  the  forward  battle  area  are  organic  to  the  maneuver  divisions,  increasing 
the  maneuver  commanders  ability  to  rely  on  engineers  in  his  exploiting  of  the 
tenets  of  AirLand  Battle. 

Personnel  and  equipment  are  held  relatively  constant  in  all  alternatives. 
This  allows  a  fair  comparison  and  the  foremost  alternative  will  be  the  one  with 
the  best  command  and  control  structure. 

1.  BACKGROUND 

As  stated  earlier,  the  three  alternatives  were  developed  as  part  of  the 
Engineer  Structure  Study.  Because  of  the  engineer  support  problem,  the 
Training  and  Doctrine  Command  (TRADOC)  Commander  instructed  the  United 
States  Army  Engineer  School  (USAES)  and  TRADOC  Analysis  Command 
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Division  Engineer  Alternative 
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Corps  Engineer  Units 


(TRAC)  to  develop  a  two  phase  analytical  effort  to  define  and  evaluate 
alternative  engineer  force  structures.  The  goal  was  to  select  an  engineer  force 
structure  to  best  support  the  heavy  corps. 

2.  Phase  I 

In  Phase  I  four  engineer  force  alternatives  were  developed  and  a 
screening  performance  analysis  was  conducted  to  measure  capabilities  versus 
requirements.  It  recommended  the  three  alternatives  described  earlier  for 
evaluation  in  Phase  II. 

•  Base  Case  (BC) 

•  Company  Restructure  (CR) 

•  Division  Engineer  (DE) 

3.  Phase  II 

Phase  II  was  designed  to  provide  an  analytical  basis  for  the  selection 
of  a  preferred  engineer  force  structure  from  the  three  alternatives  developed 
in  Phase  I.  It  focused  on  evaluating  the  responsiveness  of  engineer  command 
and  control  (C2)  capabilities  and  how  these  capabilities  contributed  to  the 
corps  overall  combat  effectiveness. 

As  part  of  this  analysis,  a  model  was  built  using  an  interactive 
graphical  design  tool  named  Modeler.  This  was  the  first  Army  analysis  to  use 
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Modeler  to  build  a  C2  analysis  simulation.  The  intent  was  to  generate  C2  time 
delays  for  input  into  CORBAN,  a  force  on  force  model.  A  description  of 
Modeler  and  the  model  designed  with  it  will  be  presented  in  chapter  3. 

The  results  of  this  C2  analysis  model  were  very  successful  in  terms 
of  providing  the  time  delays  for  the  force  on  force  model.  In  addition,  it  was 
determined  that  many  other  C2  insights  are  available  in  Modeler’s  output. 
This  thesis  uses  the  Modeler  C2  output  to  recommend  a  preferred  engineer 
force  structure  in  the  heavy  corps. 

B.  THE  THESIS  IN  OUTLINE 

The  remainder  of  the  thesis  is  organized  as  follows.  To  enable  a  better 
understanding  of  what  is  important  in  a  command  and  control  structure, 
Chapter  2  contains  a  description  of  AirLand  Battle  doctrine.  Then  the 
measures  of  performance  for  the  analysis  of  the  alternatives  are  developed.  To 
further  assist  with  the  understanding  of  the  model,  Chapter  3  begins  with  a 
review  of  Petri-Net  graphs  and  their  extension  in  Modeler.  Then  follows  a 
description  of  the  process  of  building  the  Engineer  Structure  Model  and  the 
model  itself.  In  chapter  4,  the  output  of  Modeler  is  examined.  The  method  of 
calculating  the  Measures  of  Performance,  MOP’S,  are  described  and  the  results 
stated.  Chapter  5  reports  on  historical  uses  of  Modeler  and  provides  additional 
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n.  MEASURE  OF  PERFORMANCE  DEVELOPMENT 


The  development  of  command  and  control  measures  of  performance 
requires  an  understanding  of  the  tenets  of  AirLand  Battle  and  of  the  stated 
purpose  of  command  and  control.  These  are  presented  in  FM  100-5, 
Operations.  A  summary  of  pertinent  information  appears  below. 

A.  AIRLAND  BATTLE 

Airland  battle  is  the  U.S.  Army’s  basic  fighting  doctrine.  This  doctrine 
describes  the  Army’s  approach  to  generating  and  applying  combat  power  at  the 
operational  and  tactical  levels.  It  was  developed  to  allow  for  the  lethality  and 
mobility  of  modem  warfare,  the  dynamics  of  combat  power,  and  the  application 
of  the  principles  of  war.  It  is  based  on  securing  and  retaining  the  initiative 
and  aggressively  accomplishing  the  mission.  The  Army  must  adhere  to  the 
four  tenets  of  Airland  Battle  if  it  is  to  be  successful  on  the  next  battlefield. 
These  tenets,  taken  from  FM  100-5  Operations,  are: 

1.  Initiative 

Initiative  is  the  setting  or  changing  of  the  terms  of  battle  by  action. 
It  requires  a  willingness  and  ability  of  individuals  and  leaders  to  act 
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independently.  This  requires  commanders  at  all  levels  and  subordinates  to  be 
well  informed. 

2.  Agility 

Agility  is  the  ability  of  friendly  forces  to  act  faster  than  the  enemy. 
This  quickness  permits  the  rapid  concentration  of  friendly  strengths  against 
enemy  vulnerabilities.  This  in  turn  requires  a  commander  to  communicate 
quickly  with  superiors  and  subordinates. 

3.  Depth 

Depth  is  the  extension  of  operations  in  terms  of  space,  time  and 
resources.  This  requires  the  commander  to  plan  past  his  horizons.  Operations 
in  depth  degrade  the  enemies  capabilities  by  attacking  him  before  his  forces 
join  the  battle.  Commanders  must  plan  ahead,  actively  seek  information  and 
employ  every  asset  available.  This  requires  a  staff  capable  of  doing  detailed 
planning. 

4.  Synchronization 

Synchronization  is  the  arrangement  of  battlefield  activities  in  time, 
space  and  purpose  in  order  to  produce  maximum  relative  combat  power  at  the 
decisive  point.  The  product  of  effective  synchronization  is  maximum  economy 
of  force.  This  is  achieved  through  up-to-date  information  and  quick  reliable 
communication. [Ref.  2] 
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The  purpose  of  command  and  control  is  also  clearly  stated  in  FM  100- 
5,  Operations:  "the  only  purpose  of  command  and  control  is  to  implement  the 
commander’s  will  in  pursuit  of  the  unit’s  objective."  Since  it  is  the  corps 
engineer’s  command  and  control  structure  being  studied,  and  the  fact  that 
engineers  are  a  support  arms,  it  is  clear  that  engineer  C2  must  be  evaluated 
from  the  corps  commander’s  perspective. 

"The  ultimate  measure  of  command  and  control  effectiveness  is 
whether  the  force  functions  more  effectively  and  more  quickly  than  the  enemy." 
(op.  cit.) 

In  summary,  to  support  the  tenets  of  AirLand  Battle  and  to  fulfill  the 
stated  purpose  of  command  and  control,  a  C2  structure  must  be  reliable  and 
fast;  it  must  collect,  analyze,  and  present  information;  and  it  must  issue  orders 
rapidly  and  accurately. 

B.  MEASURES  OF  PERFORMANCE 

Three  things  must  be  examined  in  order  to  evaluate  the  ability  of 
differing  C2  structures  to  support  the  maneuver  commanders.  Firstly,  which 
alternative  has  the  greatest  capacity  to  process  information.  Secondly,  which 
alternative  can  provide  the  most  accurate  and  reliable  information.  And 
thirdly,  which  alternative  can  process  information  with  the  greatest  speed. 
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1.  MOP  1:  Processing  Capacity 

Processing  capacity  is  the  ability  of  the  alternative  to  process  the 
required  information.  This  MOP  impacts  the  alternatives  ability  to  reliably 
collect,  analyze,  and  present  information.  An  alternative  can  not  present 
reliable  information  if  it  doesn’t  have  access  to  a  majority  of  available 
information. 

2.  MOP  2:  Message  Quality 

Message  quality  is  the  accuracy  and  the  reliability  of  the  information 
passed.  Two  items  determine  the  accuracy  and  reliability  of  the  staff  output. 
These  are  the  experience  level  of  the  staff  and  the  amount  of  time  available  to 
process  the  information. 

3.  MOP  3:  Processing  Speed 

Processing  Speed  is  the  speed  at  which  messages  are  processed  and 
orders  issued.  This  relates  directly  to  the  ultimate  measure  of  effectiveness  of 
functioning  more  quickly  than  the  enemy.  It  also  evaluates  the  ability  of  staffs 
to  collect,  analyze,  and  present  information  rapidly. 
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n.  MODEL  DESCRIPTION 


The  ESS  C2  model  was  built  using  Modeler  I  which  is  an  interactive, 
graphical  modeling  tool  based  on  stochastic  timed  attributed  Petri-Nete.  A 
rudimentary  understanding  of  Petri-Net  concepts  and  definitions  is  required 
in  order  to  fully  understand  the  ESS  model. 

A.  PETRI  NET  GRAPH  CONCEPTS  AND  DEFINITIONS 

Petri-Nets  have  emerged  as  an  important  tool  for  the  study  and  analysis 
of  systems.  They  allow  a  mathematical  depiction  of  the  system  and  are 
effective  at  modeling  dynamic  systems. 

A  Petri-Net  graph  is  a  bipartite  directed  multigraph  consisting  of  places 
and  transitions.  Places  are  visually  depicted  with  circles  FIG(6).  Transitions 
are  depicted  by  rectangles  and  represent  activities  in  the  model.  Places  and 
transitions  are  connected  by  directed  arcs. 

Data  flow  carriers  are  called  tokens  and  are  represented  by  dots.  The 
number  and  distribution  of  tokens  control  the  execution  of  a  Petri-Net.  A 
Petri-Net  executes  by  firing  transitions,  this  occurs  when  a  transition  is 
enabled. 


17 


* 


A  transition  is  enabled  when  each  of  its  input  places  has  a  token. 

A  transition  fires  by  combining  all  the  enablirg  tokens  from  its  input  places, 
executing  any  statements  required  by  the  transition,  and  then  depositing  the 
tokens  into  each  of  the  output  places.  Execution  of  the  Petri-Net  will  continue 
as  long  as  at  lea'  on^  transition  is  enabled. [Ref.  3] 

A  simple  example  of  a  message  center  model  for  illustrating  a  Petri-Net 
graph  is  shown  in  FIG{6)  through  FIG(9).  In  FIG(6)  there  is  only  one  staff 
member.  His  purpose  is  to  decode  incoming  messages.  He  waits  for  the 
arrival  of  a  message  (token  depicted  by  a  dot)  to  the  place,  Message  Awaits 
Staff  Member.  In  FIG(7)  a  message  has  arrived  which  enables  the  transition 
Decode  Message.  While  the  message  is  being  decoded,  another  message  t  ives 
FIG(8),  and  must  wait  for  the  staff  member  to  complete  the  decoding  before  the 
transition  is  enabled  again.  After  an  appropriate  time  delay  (needed  to  decode 
the  message)  the  transition  fires.  The  decoded  message  is  then  placed  in  the 
Outbox  place  and  the  staff  member  returns  to  the  place  Staff  Member  enabling 
the  Decode  Message  transition  again  FIG(9).  This  Petri-Net  will  continue  to 
fire  until  messages  stop  arriving. 
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B.  MODELER 


Modeler  uses  the  Stochastic  Timed  Attributed  Petri-Net  (STAPN) 
modeling  language  to  graphically  build  a  model.  In  Modeler,  places  model 
facilities,  transitions  model  processes,  and  tokens  model  objects  acted  on  by 
processes.  Modeler  has  some  extensions  of  Petri-Nets  that  are  used  in  the  ESS 
model. 

Places  may  provide  inputs  to  more  than  one  transition.  In  Modeler  all 
transitions  can  be  enabled  or  a  decision  rule  can  be  used  to  determine  which 
transition  is  enabled.  These  decision  rules  can  be  described  in  terms  of 
probabilities,  priorities,  or  functions.  They  allow  the  modeling  of  alternatives. 

Time  delays  can  be  assigned  to  transitions.  These  times  can  be  drawn 
randomly  from  parameterized  distributions,  assigned  a  constant  or  can  be 
calculated.  The  time  that  processes  require  is  represented  in  this  way. 

In  Modeler  tokens  can  be  assigned  attributes.  It  is  through  these 
attributes  that  models  from  Modeler  are  connected  with  real  world  data. 

In  addition  to  the  standard  directed  arc,  Modeler  has  two  special  arcs. 
The  first  is  the  inhibit  arc  represented  by  an  arc  with  an  unfilled  circle  at  the 
head.  A  place  connected  to  a  transition  by  a  inhibit  arc  will  not  allow  the 
transition  to  fire  if  a  token  is  in  the  place.  The  enable  arc  represented  by  an 
arc  with  a  filled  circle  at  the  head,  allows  a  transition  to  fire  but  does  not 
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consume  the  token.  The  enable  arc  is  the  one  used  in  the  ESS  model. 
[Ref.  4] 

For  the  model  description,  places  can  represent  facilities,  holding  areas 
for  tokens,  or  a  decision  point  in  the  model  flow.  Transitions  will  represent 
activities  that  can  consume  time  and/or  do  calculations.  Tokens  will  represent 
messages  or  a  control  as  to  how  a  message  is  processed.  If  the  token 
represents  a  message,  it  will  be  referred  to  as  a  message. 

The  description  of  Modeler  provided  is  sufficient  to  understand  the 
Modeler  model  used  in  the  ESS.  Many  additional  features  are  presented  in 
Modeler,  and  the  reader  is  referred  to  the  users  manual. 

C.  THE  ESS  MODEL 

1.  Model  Development 

The  ESS  model  was  built  using  Modeler  I  by  personnel  from 
ALPHATECH  (a  contractor),  TRAC  Ft.  Leavenworth  and  U.S.  Army  Engineer 
School  (USAES).  Because  no  C2  data  existed,  a  panel,  selected  by  the 
Commanding  General  of  USAES,  of  Subject  Matter  Experts  (SME)  was  formed 
to  provide  this  data.  They  followed  a  structured  process  for  generating  the 
data.  The  model  was  built  iteratively  with  the  SME’s  reviewing  each  step  and 
providing  additional  input  and  guidance.  [Ref.  5]  In  addition  the  SME’s 
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examined  the  command  and  control  situations  for  each  of  the  three 
alternatives  selected  from  Phase  I:  (Base  Case  (BC),  Company  Restructure 
(CR),and  Division  Engineer  (DE)). 

The  panel  identified  three  cases  under  which  to  analyze  the  three 
alternatives. 

а.  Three  Cases: 

•  Offense  -  Corps  attacking. 

•  Defense  -  Corps  in  the  defensive. 

•  Transition  -  Corps  going  from  the  offensive  to  the  defensive. 
The  panel  then  reviewed  the  alternatives  and  identified  eleven 

engineer  staffs  that  needed  to  be  modeled.  It  was  determined  that  the  staffs 
function  similarly  and  could  be  modeled  with  same  model  structure  but  with 
differing  input  parameters  to  account  for  differences  in  the  staffs. 

б.  Eleven  Engineer  Staffs: 

•  Forward  Divisional  Engineer  Battalion  (EBF-DIV). 

•  Forward  Corps  Engineer  Battalion  (EBF-COR). 

•  Rear  Corps  Engineer  Battalion  (ENBN-R). 

•  Division  Engineer  Headquarters  (DIVEHQ). 

•  Engineer  Group  Forward  (ENGP-F). 

•  Engineer  Group  Rear  (ENGP-R). 
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•  Engineer  Brigade  (EN  BDE). 

•  Brigade  Engineer  Section  (BDE  EN-S). 

•  Regimental  Engineer  Section  (ACR). 

•  Assistant  Division  Engineer  Section  (ADE). 

•  Assistant  Corps  Engineer  Section  (ACE). 

While  in  the  course  of  the  model  development,  eight  critical 
information  types  were  identified  to  represent  message  traffic  in  the  corps. 
Numerous  other  information  types  exist,  but  it  was  decided  that  these  eight 
would  suffice.  The  first  seven  types  are  essential  to  mission  accomplishment, 
with  the  other  routine  message  type  attempting  to  capture  the  additional 
message  traffic.  Each  message  type  is  modeled  concurrently,  although  the 
models  have  the  same  structure,  with  different  input  parameters. 
c.  Eight  Information  Types: 

•  Warning  Order  (WO) 

•  Maneuver  Operations  Order  (MO) 

•  Engineer  Operations  Order  (EO) 

•  Intelligence  Processed  Higher  to  Lower  (IN) 

•  Enemy  Information  Unprocessed  Lower  to  Higher  (El) 

•  Requests  for  Assets  (AR) 
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•  Engineer  SITREP  (ES) 

•  Other/Routine  (OT) 

Bubble  charts  were  developed  to  more  dearly  depict  information  flow 
in  the  corps.  These  bubble  charts  graphically  show  the  flow  of  C2  information 
between  engineer  and  maneuver  units  for  all  the  alternatives  and  cases.  An 
example  is  seen  in  FICK10). 

These  bubble  charts  along  with  the  information  types  and  the 
engineer  staffs,  became  the  foundation  for  the  design  of  the  C2  architecture  in 
Modeler.  With  this  foundation  the  SME’s  were  able  to  define  the  model’s 
structure  and  provide  the  necessary  inputs. 

2.  Model  Description 

The  ESS  model  measures  the  throughput  capability  of  a  headquarters 
engineering  staff  by  representing  that  staff  as  a  single  queue,  multiple  server 
system  in  which  messages  are  processed  based  on  priority,  arrival  time,  and 
availability  of  servers.  A  separate  model  was  defined  for  each  of  the  eleven 
engineer  staffs.  The  structure  of  the  model  is  the  same  for  each  staff,  however, 
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the  input  parameters  change  depending  on  the  C2  architecture,  the 
command/support  relationships,  and  the  situation. 

The  SME’s  had  to  provide  the  following  input  parameters  for  each 
message  type,  case  and  staff.  Notice  that  Modeler  notation  is  introduced.  This 
involves  a  total  of  3336  data  points. 


•  Action  Priority  -  the  order  in  which  the  staff  will  process  a 
specific  message  type  when  messages  are  in  the  queue. 

•  Rate  of  Information  -  The  number  of  information  types  received 
at  the  engineer  node  within  an  hour. 

•  Processing  Time  Minimum  (t_min)  -  The  least  amount  of  time 
a  given  staff  node  can  interpret  and  adequately  respond  to  the 
information  type. 

•  Processing  Time  Optimum  (t_opt)  -  The  amount  of  time  a  given 
staff  node  needs  to  interpret  and  best  respond  to  the  information 
types. 

•  Quality  Factor  Minimum  (q_min)  -  The  resultant  quality/worth 
of  a  processed  message  type  when  a  staff  has  only  the  minimum 
time  to  process  the  information. 

•  Quality  Factor  Optimum  (q_max)  -  The  resultant  quality/worth 
of  a  processes  message  type  when  a  staff  has  the  optimal  time 
to  process  the  information. 

•  Probability  of  Retransmit  -  The  likelihood  that  an  engineer 
staffs  dissemination  of  a  given  information  type  will  need  to  be 
retransmitted  before  it  is  received  and  acknowledged  by  each 
receiving  unit. 
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•  Time  to  Retransmit  -  The  time  it  takes  a  given  staff  to 
disseminate  a  given  information  type  to  the  receiving  unit  given 
the  information  had  to  be  retransmitted. 

The  ESS  model  consisted  of  four  components:  simulation  start-up, 
attribute  definition  and  message  generation,  node  processing,  and  output 
statistics.  This  structure  is  seen  in  FIG(ll),  with  each  box  representing  a 
submodel.  The  submodels  represented  by  the  boxes  will  be  described  in  detail. 
The  first  two  components  are  initialization  submodels,  with  the  third 
component  doing  the  actual  dynamic  modeling. 

The  last  component  calculates  the  output  statistics. 

а.  Simulation  Start-up 

The  purpose  of  the  simulation  start-up  submodel  is  to  provide  a 
time  delay.  This  assures  the  attribute  definition  and  message  generation 
submodel  has  enough  time  to  generate  enough  messages  to  insure  the  node 
processing  submodel  would  have  an  uninterrupted  flow  of  messages  during 
simulation  execution. 

б.  Attribute  Definition  and  Message  Generation 

The  attribute  definition  and  message  generation  submodels  have 
two  primaiy  purposes:  they  generate  messages,  and  provide  an  interarrival 
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Structure  of  the  ESS  Model 


time  delay  of  the  message  type  to  the  node  processing  submodel.  They 
generates  messages  by  entering  static  attributes  and  calculating  three 
additional  attributes. 

We  will  follow  a  message  through  the  (Warning  Order)  submodel 
in  the  order  of  execution  in  order  to  describe  the  execution  of  the  submodels 
in  this  component.  An  example  of  the  Warning  Order  portion  of  the  submodel 
is  seen  in  FIGK12).  Each  of  the  information  type’s  submodels  has  the  same 
structure  as  this  one  and  executes  concurrently  with  the  Warning  Order 
submodel,  this  is  shown  in  FIG(11). 

Three  places  have  been  assigned  tokens  when  the  simulation  is 
started.  The  place  cycle  has  only  one  token,  which  ensures  only  one  message’s 
attribute  calculations  is  done  at  a  time.  Another  token  exists  in  the  place 
init_mssg_attrib8  which  stamps  each  token  with  the  initial  attributes  (input 
parameters)  defined  by  the  SME’s.  The  third  token  comes  from  the  place 
max_num_mssgs  which  calculates  how  many  messages  for  a  given  staff  will 
occur  during  the  time  of  the  simulation.  This  is  calculated  by  the  simulation 
time  (15  days  for  ESS)  divided  by  the  average  rate  of  arrival  as  defined  by  the 
SME’s.  This  place  will  determine  how  many  times  the  create_init_mssgs 
transition  will  fire.  Thereby  it  determines  how  many  times  this  submodel  is 
executed. 
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The  transition  create_init_mssgs  fires  immediately,  this  creates 
a  warning  order  message.  This  message  then  has  three  attributes  calculated 
in  parallel.  These  attributes  will  be  used  in  the  node  processing  submodel. 
The  three  attributes  calculated  are:  time  to  transmit  (t_com),  time  required  to 
process  this  message,  (tr_treq),  and  a  processing  tune  between  the  minimum 
processing  time  and  the  optimum  processing  time  (un_tmin_topt). 

The  time  to  retransmit  (t_com)  is  the  time  to  retransmit  a 
message  and  receive  back  an  acknowledgement  from  the  receiving 
headquarters.  It’s  value  is  determined  as  stated  below: 

0  if  a  random  variable  <  input  parameter 

•_com  =  i 

t_retran  otherwise  (SME  input  data) 

The  time  required  to  process  the  message  (trjreg)  is  the  time  to 
process  the  message,  plus  the  time  to  communicate  it,  if  no  retransmisson  is 
needed,  plus  the  time  to  receive  back  an  acknowledgement  from  the  receiving 
headquarters. 

The  time  to  process  our  message  (tr_reg)  is  drawn  from  a 
triangular  distribution.  The  minimum  value  of  the  distribution  is  equal  to  the 
minimum  processing  time  plus  the  time  to  communicate  the  message.  The 
maximum  value  of  the  distribution  is  equal  to  the  mayimnm  time  that  will  be 
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takeii  to  process  plus  the  time  to  communicate  the  message.  The  mode  is 
calculated  as  stated  below: 

mode  ■=  min  .25  (max  -  min)  (offense) 

=  min  +  .75  (max  -  min)  (defense) 

=  min  +  .£  (max  -  min)  (transition) 

The  different  modes  are  described  in  this  way  because  of  the  urgency  of  the 
information  under  the  different  corps  mieeions. 

The  processing  time  will  be  a  random  uniform  draw  between  the 
minimum  processing  time  (t_min)  and  the  optimum  processing  time  (t_opt). 
This  time  will  be  used  in  the  node  processing  submodel  if  the  time  available 
to  process  the  message  is  greater  than  the  time  until  the  message  is  due.  This 
is  done  to  capture  the  notion  that  staffs  do  not  spend  all  available  time 
processing  every  message. 

The  transition  combine  will  fire  once  all  the  attributes  are 
calculated.  This  will  enable  create_init_mssgs  again  if  max_num_mssgs  has 
not  been  reached  and  will  put  ox.'-  message  in  the  plac*  waming_orders.  The 
messages  will  accumulate  in  waming_orders  until  the  time  delay  from  the 
sin  *■ vJation  start_up  submodel  expires. 
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At  the  end  of  the  delay  from  the  simulation  start_up,  the 
transition  offset  will  fire  giving  a  one  time  delay  of  the  first  message  to  assure 
there  is  a  time  separation  between  the  arrival  of  the  first  message  of  each 
information  type. 

Once  offset  has  fired,  the  transition  wo_interarrival_delay  will 
fire  sending  messages  to  the  node  processing  submodel  according  to  the 
distribution  of  interarrival  times  defined  by  the  SME’s.  Our  message  will  then 
go  to  the  node  processing  submodel. 
c.  Node  Processing 

In  the  node  processing  submodel  all  messages  for  the  engineer 
staff  are  processed.  It  is  in  this  submodel  that  the  dynamics  of  the  system  are 
described.  A  graphical  depiction  of  the  model  as  it  appears  in  Modeler  is  seen 
in  FICK13).  We  will  again  examine  how  this  submodel  functions  by  following 
a  message  through  the  model. 

As  our  message  is  generated  from  one  of  the  eight  message  type 
interarrival_delay  transitions  it  enables  the  transition  receive_mssgs.  It  is 
stamped  with  the  time  it  was  received  and  the  time  it  is  due  is  calculated.  The 
message  is  then  prioritized  according  to  the  SME’s  input  and  it’s  time  of 
arrival  in  the  place  mssg_q.  Here  it  waits  for  an  available  staff  member.  The 
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NODE  PROCESSING 


Figure  13 


number  of  tokens  in  the  place  staff  is  determined  by  the  size  of  the  engineer 
staff  thus  determining  how  many  messages  can  be  processed  simultaneously. 

Once  a  staff  member  is  available  the  transition  calc_tavail  fires 
calculating  how  much  time  is  available  to  process  our  message.  A  decision  rule 
at  the  place  can_i_process  determines  which  of  the  three  paths  our  message 
will  take  based  on  the  time  available  (t_avail)  to  process  the  message. 

If  there  is  not  enough  time  to  process  our  message,  the 
transition  tavail_less_than_tmin  fires.  The  message  is  stamped  with  its 
completion  time  and  the  time  it  waited  to  be  processed.  It  is  then  placed  in 
the  output  box.  The  staff  member  then  returns  to  the  place  staff  and  is  then 
available  to  process  another  message. 

If  the  time  available  is  greater  than  the  optimal 
(maximum)  time  it  takes  to  process  our  message,  (i.e.  there  is  more  time 
available  then  the  staff  will  use),  the  transition  tavail_greater_than_topt  fires. 
The  SME’s  decided  that  a  staff  would  not  normally  take  the  maximum  time  to 
process  a  message  even  if  it  is  available.  To  model  this,  the  time  to  process  a 
message  when  the  time  available  is  greater  than  the  maximum  time  required 
is  drawn  from  a  uniform  distribution  with  the  minimum  value  equal  to  the 
minimum  processing  time  (t_min)  plus  the  communication  time,  and  the 
maximum  value  equal  to  the  optimal  processing  time. 
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If  the  time  available  is  greater  than  the  minimum  processing 
time,  but  less  than  the  optimal  processing  time,  the  time  to  process  the 
message  (t_process)  will  equal  the  time  available  (t_avail).  This  models  a  staff 
person  working  under  a  time  constraint  and  getting  what  ever  information  he 
has  out  when  it  is  needed. 

After  the  processing  time  has  been  calculated  our  message 
proceeds  to  the  logical  place  processing.  It  will  remain  in  this  place  having  the 
time  remaining  to  process  decreased  by  the  transition  processjmssg  until  the 
message  is  preempted  or  until  the  message  is  90%  processed.  The  value  90% 
was  selected  as  the  point  were  a  person  would  just  finish  what  he  was  doing 
rather  than  put  it  down  to  start  a  new  message.  There  are  two  paths  by  which 
our  message  can  escape  this  place. 

Our  message  will  get  preempted  if  there  is  a  message  in  the 
queue  with  a  higher  priority,  no  Btaff  member  is  available,  and  less  than  90% 
of  the  message  has  been  processed.  This  is  modeled  in  Modeler  by  the  enable 
arc  (the  arc  from  mssg_q  and  the  transition  preempt).  The  preempted  message 
will  be  marked  and  the  time  spent  will  be  recorded.  It  will  then  be  put  back 
into  the  queue  and  the  staff  member  will  become  available  for  the  higher 
priority  message. 
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Once  our  message  is  90%  completed,  it  will  enable  the 
complete_processing  transition.  This  transition  stamps  the  message  with  its 
completion  time  and  places  it  in  the  output  box.  The  staff  member  becomes 
available  after  the  message  is  completely  processed.  The  message  then  enters 
the  last  submodel  and  has  it’s  output  attributes  calculated. 

When  the  submodel  is  finished,  all  messages  are  either  processed  or 
unprocessed.  The  last  submodel  then  completes  output  calculations. 
d.  Output  Statistics 

In  the  output  statistics  submodel  the  messages  are  sorted  and 
output  statistics  are  calculated.  The  output  from  MODELER  consisted  of: 

•  Processing  time  delay-  (minimum,  maximum,  and  average) 
time  it  took  to  process  messages  of  a  specific  message  type. 

•  Waiting  time  delay-  (minimum,  maximum,  and  average) 
time  a  message  waits  to  be  processed. 

•  Quality  factor-  (minimum,  maximum,  and  average)  the 
quality  of  a  processed  message  at  each  staff  by  type  based 
on  the  time  it  took  to  process  the  message. 

•  Total  time  delay-  (minimum,  maximum,  and  average)  sum 
of  the  processing  time,  waiting  time,  and  transmission  time 
to  the  receiving  staff. 

•  The  number  of  processed,  partially  processed,  and 
unprocessed  messages  by  type  and  staff. 
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The  model  is  stochastic  so  the  variability  of  its  output  was 
examined  by  running  10  replications  of  the  ADE  base  case  offense.  FIG(14)  is 
a  graphical  presentation  of  the  number  of  messages  processed,  partially 
processed  and  unprocessed  for  each  run.  In  addition,  a  95%  confidence  interval 
was  constructed  around  the  sample  mean  of  the  total  time  delay  for  each 
message  type  using  the  t-statistic  with  9  degrees  of  freedom. 

The  length  of  the  largest  confidence  interval  was  ±  5%  of  the 
sample  mean.  The  lack  of  variation  is  attributed  to  the  limits  placed  on  the 
processing  time,  the  required  time,  and  the  interarrival  times. 

Due  to  time  constraints,  the  purpose  of  the  study,  and  the  results  above,  it  was 
decided  that  a  single  replication  of  each  case  was  sufficient. 
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Variation  in  Ten  Replications 

ADE  BC  Offense  OPCON 


IV.  ANALYSIS  OF  THE  THREE  C2  ALTERNATIVES 


A.  INSIGHTS  FROM  THE  DATA 

The  output  from  Modeler  is  not  in  a  form  that  can  be  used  to  evaluate  the 
three  alternatives.  The  data  represents  how  each  staff  performed,  not  how  the 
command  performed  as  a  whole.  This  can  be  seen  in  FIG(15)  where  there  is 
no  direct  comparison  of  nodes. 

In  this  figure,  the  engineer  battalion  forward  divisional,  (EBF-DIV)  is 
compared  in  each  of  the  three  alternatives.  Yet  this  battalion  is  distinctly 
different  in  each  alternative.  Under  the  Base  Case  and  Company  Restructure 
alternative,  the  battalion  supports  a  division;  while  under  the  Division 
Engineer  alternative  it  supports  a  brigade. 

Additionally  each  node  contributes  differently  to  the  corps.  As  an 
example,  in  the  Base  Case  there  is  only  one  engineer  brigade  (EN-BDE)  but, 
the  number  of  brigade  engineer  sections  (BDE  EN-S)  is  dependent  on  the 
number  of  divisions  in  the  corps.  In  our  notional  four  division  corps  there 
would  be  twelve  brigade  engineer  sections.  There  are,  however,  some  insights 
that  can  be  drawn  from  the  data. 
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Message  Processing  by  Node 
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The  goal  of  any  staff  is  to  process  all  incoming  messages.  The 
performance  of  each  staff  in  each  case  can  be  seen  in  FIG(16)  through 
FIG<18).  From  the  figures  one  can  see  only  the  division  engineer  headquarters 
in  the  offense  case  was  able  to  process  all  incoming  messages.  In  addition, 
there  are  certain  staffs  that  perform  noticeably  poorer  than  the  others.  These 
staffs  are:  the  brigade  engineer  section,  the  armored  calvary’s  engineer 
section,  and  the  assistant  corps  engineer  section.  These  three  staffs 
performances  must  be  improved  under  any  alternative  selected. 

Further  evaluation  of  the  alternatives  is  impossible  with  the  data  in  its 
present  form.  There  is  no  staff  to  staff  comparison  between  the  alternatives 
and  some  staffs  have  different  functions  in  each  alternatives. 

B.  ANALYSIS  METHODOLOGY 

The  model  output  must  be  manipulated  so  the  MOP’s  derived  earlier  are 
viable.  One  of  the  keys  to  evaluating  the  alternatives  is  to  view  them  from  the 
corps  commander’s  perspective.  To  fully  understand  his  perspective,  the  effects 
of  the  different  engineer  C2  structures  on  the  corps  commander’s  primary 
maneuver  commanders  must  be  understood.  These  maneuver  commanders  are 
his  division  commanders  and  the  brigade  commanders. 
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DEFENSE  MESSAGE  PROCESSING 

Capabilities  vs.  Requirements 
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BFD  BFC  DHQ  BnR  GpF  GpR  Bde  BdeES  ACR  ADE  ACE 

Figure  1 7 


5pF  GpR  Bde  BdeES  ACR  ADE  ACE 
Figure  1 8 


Phase  I  •allocation  rules,  which  dictate  how  many  engineer  units  are 
assigned  to  a  corps,  were  U3ed  to  determine  each  engineer  staffs  contribution 
to  a  notional  four  division  corps.  The  engineer  organization  of  the  notional 
corps  is  shown  in  Table  1.  Divisional  and  brigade  task  organization  are  shown 
in  Trble  2  and  Table  3  respectively. 

The  average  output  data  from  Modeler  was  used  to  further  build  the 
alternatives.  It  is  reasonable  to  believe  that  the  simulation  reached  steady 
state  since  it  simulated  15  days  of  war.  This  methodology  allows  a  direct 
comparison  of  the  alternatives.  Each  of  the  MOP’s  developed  earlier  will 
utilize  this  methodology. 
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TABLE  1 


NUMBER  OF  ENGINEER  STAFFS  IN  THE  CORPS  BY  ALTERNATIVE 


TABLE  2 


NUMBER  OF  ENQNEER  STAFFS  IN  THE  0IVI9ONS  BY  ALTERNATIVE 


TABLE! 


NUMBER  OF  ENGINEER  STAFFS  IN  THE  BRIGADES  BY  ALTERNATIVE 
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C.  OFFENSIVE  CASE  RESULTS 


1.  MOP  1:  Processing  Capacity 

Processing  capacity  is  the  ability  of  the  alternative  to  process  the 
required  information.  This  MOP  examines  each  alternatives  ability  to  collect, 
analyze,  and  present  information.  It  is  the  percentage  of  messages  processed 
at  each  maneuver  level  for  each  of  the  cases,  and  is  calculated  as  follows: 

LET  i  =  1,2,.. .,11  represent  the  staffs  EBF-DIV,  EBF-COR, 

ENBN-R,  DIVEHQ,  ENGP-F,  ENGP-R,  EN  BDE,  BDE  EN-S, 
ACR,  ADE,  ACE. 

DEFINE  for  i  =  1,2 . 11 

Xj  =  the  number  of  type  i  engineer  staff  in  the  command. 

Yi  =  the  number  of  messages  processed  per  type  i 
engineer  staff. 

Zj  =  the  total  number  of  messages  generated  per  type 
i  engineer  staff. 

PERCENT  OF  MESSAGES  PROCESSED  FOR  EACH  ALTERNATIVE 


r 

ixiYi 


for  each  alternative  i  =  1,2,  ... , 


11. 


An  example  of  this  calculation  for  the  Base  Case  offense  for  the 
brigade’s  warning  orders  is  (8  corps  engineer  battalions  *  20  warning  orders 
processed  per  corps  battalion  +  12  brigade  engineer  sections  *  19  warning 
orders  processed  per  section  /  8  corps  engineer  battalions  *  20  warning  orders 
generated  per  corps  battalion  +  12  brigade  engineer  sections  *  20  warning 
orders  generated  per  section)  *  100  =  (160  +  228  /  160  +  240)  *  100  =  97% 
warning  orders  processed  in  the  corps’s  maneuver  brigades. 

MOP1  is  calculated  for  each  message  type  and  each  alternative  with 
corps,  division  and  brigade  level.  The  following  table  contains  these  results. 


TABLE  4 


OFFENSE  CASE  PROCESSING  CAPACITY  PERCENT  MESSAGES  PROCESSED 
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From  this  table  we  can  see  the  effects  of  the  prioritization  of  the 
message  types.  All  three  alternatives  at  each  of  the  three  levels  of  command 
perform  well  on  the  three  highest  priority  message  types.  After  the  three 
highest  priorities  the  base  case  and  company  restructure  alternatives  perform 
noticeably  poorer  than  the  division  engineer  alternative. 

The  effects  of  moving  more  equipment  and  personnel  into  the 
divisions  without  providing  for  additional  command  and  control  degrades  the 
company  restructure  alternative  performance.  This  is  evident  in  the  company 
restructures  extremely  poor  performance  in  the  lowest  priority  messages  at  the 
brigade  level. 

By  summing  over  all  the  message  types  we  get  the  over  all  processed 
percentage  for  each  of  the  levels  of  command  by  alternative.  These  results  can 
be  seen  in  FIGK19).  Clearly  the  Division  Engineer  alternative  out  performs  the 
other  two. 

2.  MOP  2:  Message  Quality 

Message  quality  is  the  accuracy  and  the  reliability  of  the  information 
passed.  Message  quality  is  scored  on  a  scale  of  0  to  1.  Quality  is  determined 
by  the  experience  of  the  staff  (SME  Input)  and  the  amount  of  time  available 
to  process  the  message.  Message  quality  will  be  summarized  by  computing  a 
command  average. 
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Processing  Capacity  -  Offense 

Percent  of  Messages  Processed 
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LET  i  =  1,2 . 11  represent  the  staffs  EBF-DIV,  EBF-COR, 

ENBN-R,  DIVEHQ,  ENGP-F,  ENGP-R,  EN  BDE,  BDE  EN-S, 


ACR,  ADE,  ACE. 

DEFINE  for  i  =  1,2,.. .,11 

Xj  =  the  number  of  type  i  engineer  staff  in  the  command. 

Y;  =  the  number  of  messages  processed  per  type  i 
engineer  staff . 

Zj » the  average  quality  value  of  the  messages  processed  by  type 
i  engineer  staff. 

AVERAGE  MESSAGE  QUALITY  IN  THE  COMMAND 

^xiYizi 

_ _  for  each  alternative  i  =  1,2,  ...  ,11 . 


An  example  of  this  calculation  for  the  Base  Case  offense  for  the  brigade’s 
warning  orders  is  (8  corps  engineer  battalions  *  20  warning  orders  processed 
per  corps  battalion  *  0.54  the  average  message  quality  in  a  corps  battalion  + 
12  brigade  engineer  sections  *  19  warning  orders  processed  per  section  *  0.42 
the  average  message  quality  in  the  brigade  engineer  section  /  8  corps  engineer 
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battalions  *  20  warning  orders  processed  per  corps  battalion  +  12  brigade 
engineer  sections  *  20  warning  orders  processed  per  section)  =  (86.4  +  95.76  / 
160  +  228)  s  0.4695  average  message  quality  in  the  corps’s  maneuver  brigades. 

This  is  done  for  each  message  type  and  each  alternative  with  the 
results  in  the  following  table  at  corps,  division  and  brigade  level.  The 
following  table  contains  these  results. 


TABLE* 


OFFENSE  CASE  PffOCESSMG  SPEED  OF  MESSAGES  PROCESSED 
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From  the  table  it  is  clear  that  Division  Engineer  produces  higher 
quality  messages  at  every  command  level  and  for  each  message  type. 


We  then  sum  over  all  the  message  types  to  get  the  over  all  message 
quality  for  each  of  the  levels  of  command  by  alternative.  These  results  can  be 
seen  in  FIGK20).  The  Division  Engineer  attains  higher  message  quality  scores 
than  the  other  alternatives. 

3.  MOP  3:  Processing  Speed 

Processing  Speed  is  the  speed  at  which  messages  are  processed  and 
orders  issued.  This  MOP  examines  how  fast  each  alternative  is  able  to  collect, 
analyze,  present  information  and  issue  orders. 

LET  i  =  1,2,. ..,11  represent  the  staffs  EBF-DIV,  EBF-COR, 
ENBN-R,  DIVEHQ,  ENGP-F,  ENGP-R,  EN  BDE,  BDE 
EN-S,  ACR,  ADE,  ACE. 

DEFINE  for  i  =  1,2,. ..,11 

Xj  =  the  number  of  type  i  engineer  staff  in  the  command. 
Yj  =  the  number  of  messages  processed  per  type  i  engineer 
staff. 

Z,  -  the  average  total  dels  v  value  of  the  messages  processed 
by  type  i  engineer  staff. 

AVERAGE  MESSAGE  TOTAL  DELAY  IN  THE  COMMAND 

■ .  for  each  alternative  i  =  1,2,. ..,11. 

iVi 
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Message  Quality  -  Offense 

Average  Message  Quality 


The  results  of  these  calculations  are  shown  in  the  following  table. 


TABU* 


OFFENSE  CASE  PROCESSOR]  SPSS  OF  MESSAGES  PROCESSED 
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Processing  speed  measures  how  fast  a  staff  can  collect,  analyze,  and 
provide  the  information  to  those  who  need  it.  This  is  extremely  critical  in  the 
forward  battle  area,  where  the  situation  changes  rapidly.  The  Division 
Engineer  alternative  excels  at  providing  information  rapidly  at  all  levels  of 
command,  but  most  notably  in  the  forward  battle  area.  This  can  be  seen  from 
the  table  at  the  brigade  level. 


56 


The  overall  total  time  delay  average  for  each  of  the  levels  of 
command  by  alternative  can  be  seen  in  F1GK21).  Again,  the  Division  Engineer 
alternative  achieves  superior  results. 

D.  DEFENSIVE  CASE  RESULTS 

There  are  four  alternatives  in  the  Defense  Case.  In  this  case  the  Base 
Case  was  modeled  using  two  different  command  and  support  relationships. 
Historically  and  doctrinally,  engineers  have  been  placed  in  direct  support  of 
the  maneuver  units  during  defensive  operations.  This  was  done  to  centralize 
engineer  planning  and  operations.  In  recent  years  it  became  evident  that  this 
command  and  support  relationship  was  not  responsive  enough  for  the 
maneuver  commanders.  The  corps  in  Europe  changed  this  command  and 
support  relationship  to  operational  control.  The  results  here  indicate  that  this 
was  a  good  decision.  Operationally  controlled  command  and  support  is 
preferred  over  the  direct  support  command  and  support  relationship. 

1.  MOP  1:  Processing  Capacity 

The  results  with  the  corps  in  the  defense  are  very  similar  to  the 
Offensive  Case.  Table  7  contains  these  results. 

The  effects  of  the  prioritization  of  the  message  types  can  still  be  seen. 
All  four  alternatives  at  each  of  the  three  levels  of  command  perform  well  on 
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Processing  Speed  -  Offense 

Time  Delay  Average 
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the  highest  priority  message  types.  Once  again,  the  Base  Case  and  Company 
Restructure  alternatives  performed  noticeably  poorer  than  the  Division 
Engineer  alternative  in  the  lower  priority  message  types. 

The  overall  processed  percentage  for  each  of  the  levels  of  command 
by  alternative  can  be  seen  in  FIG(22).  Clearly  the  Division  Engineer 
alternative  out  performs  the  others. 

2.  MOP  2:  Message  Quality 

Message  quality  is  calculated  the  same  in  the  defense  case  as  in  the 
Offense  Case  with  similar  results.  Table  8  contains  these  results. 

The  overall  command  average  for  each  of  the  levels  of  command  by 
alternatives  can  be  seen  in  FIGK23).  The  results  are  similar  to  the  Offense 
Case,  with  Division  Engineer  out  performing  the  other  alternatives  in  message 
quality. 

3.  MOP  3:  Processing  Speed 

The  results  for  processing  speed  under  this  case  are  also  similar  as 
shown  in  Table  9.  FICK24)  shows  the  overall  total  time  delay  average  for  this 


Processing  Capacity  -  Defense 

Percent  of  Messages  Processed 
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Figure  22 
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Message  Quality  -  Defense 

Average  Message  Quality 
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E.  TRANSITION  FROM  OFFENSE  TO  DEFENSE  CASE  RESULTS 


Transitioning  from  offense  to  defense  is  a  critical  time  for  engineers. 
They  must  quickly  consolidate  their  units,  and  determine  the  status  of  their 
equipment.  They  must  coordinate  plans  with  maneuver  forces  and  quickly 
begin  work  on  obstacles  and  survivability  positions.  This  is  crucial  because 
these  task  are  time  consuming. 

1.  MOP  1:  Processing  Capacity 

The  performance  of  all  alternatives  decrease  because  of  the  confusion 
during  this  transition.  While  the  Division  Engineer  alternative’s  performance 
decreased  somewhat,  it's  advantages  are  seen  even  in  the  highest  priority 
message  types  when  compared  to  the  other  alternatives.  This  is  seen  in  Table 
10. 

The  overall  percentage  of  processed  messages  are  shown  in  FIG(25). 
The  Division  Engineer  alternative  is  still  the  best. 

2.  MOP  2:  Message  Quality 

In  this  case,  the  Division  Engineer  alternative  has  higher  quality 
messages  at  all  levels  of  command  for  all  message  types.  The  results  for  this 
MOP  are  shown  in  Table  11. 
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Processing  Capacity  -  Transition 

Percent  of  Messages  Processed 
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The  overall  case  average  message  quality,  by  alternative  and  level  of 


command  is  shown  in  FIGK26). 

3.  MOP  3:  Processing  Speed 

In  this  case,  Company  Restructure  has  a  faster  processing  speed  for 
two  of  the  lower  priority  messages.  This  is  due  to  the  small  number  of  these 


type  messages  generated  and  processed  in  this  case. 

TABLE  11 
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The  overall  processing  speed  for  the  alternatives  by  level  of  command 
is  shown  in  FIG(27).  Division  Engineer  is  still  noticeably  faster. 


69 


Message  Quality  -  Transition 

Average  Message  Quality 
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Processing  Speed  -  Transition 

Time  Delay  Average 
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F.  OVERALL  CONCLUSION 

The  Division  Engineer  alternative  has  emerged  as  the  foremost  engineer 
force  structure.  If  the  compounding  effects  of  the  MOP’S  on  each  other  were 
taken  into  account,  Division  Engineer  alternative  would  become  even  a 
stronger  performer.  The  Division  Engineer  force  structure  processes  more 
information  with  higher  quality  output,  and  does  it  faster  than  the  other 
alternatives  at  eveiy  level  of  command  and  for  every  corps  mission. 
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V.  USES  OF  MODELER 


Modeler  is  a  simulation  tool  developed  for  the  Air  Force  to  analyze  foreign 
Command  and  Control  systems.  Modeler  allows  for  an  automated  means  for 
constructing  Stochastic,  Timed,  Attributed  Petri  Nets  (STAPNs),  simulating 
the  underlying  operations  of  such  systems. 

The  version  of  the  software  we  are  interested  in  is  Modeler  1.  It  runs  on 
a  SUN  work  station  utilizing  the  SUN  OS  operating  system.  Its  graphics 
capabilities  are  provided  by  X-windows  11.0.  The  software  developer 
ALPHATECH  believes  that  with  a  small  number  of  modifications  the  product 
should  run  on  any  system  with  4-8  Megabytes  of  random-access  memory,  100 
Megabytes  of  on-line  disk-based  storage,  and  able  to  run  a  C  compiler  and  X 
windows.  [Ref.  6] 

A.  HISTORICAL  USES  OF  MODELER 

In  addition  to  the  ESS,  Modeler  has  been  used  on  two  other  studies.  Both 
of  these  studies  were  conducted  by  the  Navy.  The  purpose  of  both  of  these 
studies  were  to  demonstrate  Modeler’s  ability  to  model  Navy  Command  and 
Control  systems. 


B.  FURTHER  USES  OF  MODELER 

The  world  has  witnessed  unprecedented  events  over  the  last  few  years. 
These  events,  along  with  the  development  of  Airland  Battle  Future,  will 
require  the  Army  to  consider  changes  in  it’s  force  structure  and  introductions 
of  new  technologies  onto  the  battlefield.  These  changes  will  require  the  Army 
to  evaluate  it’s  Command  and  Control  structure  at  all  levels  and  in  all 
theaters. 

Modeler  provides  the  military  analyst  with  a  powerful  tool  to  assist  in  the 
design  of  and  improvement  of  existi*  *  command  and  control  systems. 

Modeler  has  a  wide  ranee  of  uses.  It  can  model  a  staff  in  detail  or  an 
aggregated  system.  Ana1  /sis  at  every  level  of  the  Army  hierarchy  can  develop 
uses  for  Modeler. 

Some  suggested  areas  for  rurther  analysis  are: 

•  Distriouii'm  of  supplies  in  the  corps. 

•  Command  and  Control  in  Post  Warsaw  Pact  Europe. 

•  Command  and  Control  of  Air  Defense  in  the  co~ps. 

•  Medical  evacuations  in  the  corps. 

•  Command  and  Control  of  counter-drug  enforcement. 

•  Command  and  Control  of  deployment  operations. 
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This  list  is  by  no  means  exhaustive,  but  analyzing  these  areas  will  further 
develop  the  methodology  for  command  and  control  and  systems  analysis. 
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VL  CONCLUSION 


A.  RESULTS 

The  Division  Engineer  alternative  is  the  best  engineer  force  structure  to 
support  the  heavy  corps.  It  consistently  outperformed  the  other  alternatives 
in  every  measure  of  performance  and  in  every  case. 

The  performance  measures  obtained  at  the  corps  in  each  of  the  three 
cases  are  summarized  in  Tables  (13)  through  (15). 


TABLE  13 


OFFENSE  CASE 

ALT  ALTA 

BASE 

COMPANY 

DIVISION 

MOP 

CASE 

RESTRUCT 

PROCESSING 

CAPACITY 

67.00% 

65.00% 

* 

89.00% 

MESSAGE 

QUALITY 

0.55 

0.57 

* 

0.65 

PROCESSING 

SPEED 

2.73 

2.79 

* 

2.13 

*  INDICATES  BEST  PERFORMANCE 
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ALT  ALT  A 


MOP 


PROCESSING 

CAPACITY 


MESSAGE 

QUALITY 


PROCESSING 

SPEED 


DEFENSE  CASE 

BC 

BC 

COMPANY 

DIVISION 

OPCON 

DS 

RESTRUCT 

ENGINEER 

63.00% 

56.00% 

62.00% 

* 

85.00% 

0.60 

0.60 

0.61 

* 

0.66 

2.39 

2.84 

2.74 

* 

2.15 

*  INDICATES  BEST  PERFORMANCE 


TABLE  15 


TRANSITION  CASE  | 

ALT  ALT  A 

BASE 

COMPANY 

DIVISION 

MOP 

CASE 

RESTRUCT 

ENGINEER 

PROCESSING 

CAPACITY 

48.00% 

59.00% 

* 

78.00% 

MESSAGE 

QUALITY 

0.57 

0.55 

* 

0.67 

PROCESSING 

SPEED 

_ 

3.36 

2.96 

* 

2.63 

*  INDICATES  BEST  PERFORMANCE 
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The  Division  Engineer  force  structure  processes  more  information  with 
higher  quality  output,  and  does  it  faster  than  the  other  alternatives  at  every 
»  level  of  command  and  for  every  corps  mission. 

B.  RECOMMENDATIONS 

Implement  the  engineer  force  structure  described  by  the  Division 
Engineer  alternative  in  the  armored  and  mechanized  corps  immediately. 
Continue  research  to  determine  if  a  Division  Engineer  type  alternative  is 
appropriate  for  Army  wide  implementation. 

Modeler  proved  to  be  a  useful  tool  in  the  analysis  of  engineer  force 
structures.  We  should  exploit  the  features  of  Modeler  in  future  Army  analysis 
of  systems  and  command  and  control  structure. 
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